Thanks for opening this pull request!

• ❌ Please link an issue that describes the reason for this pull request, otherwise your pull request will be closed. Make sure to write it as Related issue: #123 in the PR description, so I can recognize it.

Does this influence existing built-in log messages? If so, maybe this should be optional, because logging object attributes may expose sensitive data in the logs.

Yes it does, that's why it defaults to false at the moment

Alright, maybe we can add a short warning note about that to the option JSdoc.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (d098c00) to head (0e71000).

@@            Coverage Diff            @@
##             alpha     #1594   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           64        64           
  Lines         6238      6245    +7     
  Branches      1450      1467   +17     
=========================================
+ Hits          6238      6245    +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Does this influence existing built-in log messages?

The symbols are scoped locally per object and doesn't influence existing built in logs

@mtrezza This is ready for review

I believe I was referring to when using the Parse SDK in Cloud Code, whether that will output additional logs to the requester, which may expose information about the object, for example in case of an error.

The requester will never see this right?

That depends on what the server sends to the requester in case of an error. I don't know whether there is currently an error handling anywhere in Parse Server that would cause the full object being returned to the requester.

In any case, I think my question back then was referring to the log files on the server side. Sensitive information should also not be in the log files by default. Maybe that's good for development, so if it's off by default that should be fine. I would just add an extra warning note to the option's doc that this should not be enabled in production. Maybe log a warning as well.